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(54) Window management 

(57) A method and apparatus for establishing an al- 
ways-visibta class of windows in a computer-implement- 
ed windowing environment is provided. A user nr^y des- 
ignate one or wore windows (204. 206) as always-visi- 
ble windows. If an always-visible window (204, 206) 
overlaps with a non-always-visible window (208. 210). 
then the always-visible window is displayed on top of 
the non-always-visible window. Always^isible windows 



are prevented from overlapping with each other. Tech- 
niques are provided for implementing the always-visible 
window class in a manner that complies with the X Win- 
dows system. According to one technique, the override 
redirect attribute is used as a flag to designate which 
windows are always-visible windows. According to an 
alternative technique, a list of alway8-vi8ibl& windows is 
maintahed as a property attached to a root window. 
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Description 

The present invention relates to window manage- 
ment on computer systems. A preferred form of imple- 
mentation of the Invention relates to a method and ap- 
paratus for displaying a class of always-visible windows 
in an X Windows system. 

A window is a user interface object that establishes 
a correlation between a particular set of data and a par- 
ticular screen region. Unless the window is hidden or 
covered by another user interlace object, the set of data 
is typically displayed in the con^esponding screen re- 
gion. The use of windows has proven to be an effective 
way of conrvnunicattng information to a computer user. 
For example, a word processing system that allows a 
user to open multiple documents may provide a sepa- 
rate window for displaying the contents of each of the 
open documents. 

For added flexibility, many window management 
systems albw windows to overlap with each other. Two 
windows overlap when there is an intersection between 
the screen regions associated with the windows. If the 
contents of two or more overlapping windows are dis- 
played in the common screen region, the information 
may appear garbled and difficult to read. Consequently, 
the window management system must determine what 
should be displayed in the region that is common to 
overlapping windows. 

To address this problem raised by overlapping win- 
dows, most window management systems assign each 
window a position in a 'stack order*. When multiple win- 
dows share the same screen region, only the informa- 
tion from the window that has the higher position in the 
stack order is shown in the screen region. Thus, the por- 
tion of the lower-ordered window that corresponds to the 
common screen region will be 'covered' by the portion 
of the higher-ordered window that corresponds to the 
common screen region. To a user, this makes the kDwer- 
ordered window appear as if it were physically betow the 
higher-ordered window. 

Most window management systems allow users to 
move, resize and change the stack order of indivkJual 
windows. For example, in the System 7 operating sys- 
tem available from Apple Computer. Inc., a window as- 
sumes the highest posrtk>n in the stack order when a 
user clicks on a portion of the window using an input 
device such as a mouse ortrackball. A window is resized 
by dragging the bottom comer of the window until the 
window has the desired dimensions. A window is moved 
by dragging the title bar of the wirKk>w to a new position 
on the screen display. 

In some applications, it may be important to ensure 
that certain information is always visible to the user. 
However, if the information is displayed in a window in 
a system that albws windows to overlap, then the vital 
information may become hidden from the user. For ex- 
ample, the lnformatk>n may become covered if the user 
performs some action that would cause a window that 



is higher in the stack order to overlap with the given win- 
dow. Numerous types of user actions can cause this sit- 
uatbn to arise. For example, the user may cause an al- 
ready-overlapping window to assume a position in the 
s stack order that is higher than the position of the given 
window. Altematively, the user may nnove a window that 
is already higher in the stack order to a screen positksn 
that overlaps with the given window. 

Various attempts have been made to prevent impor- 
10 tant informatbn displayed in a window from becoming 
hidden to the user. For example, PC Tools for Windows 
provides a window-based graphical desktop that allows 
a user to specify that a window should remain 'always 
on top". The 'always on top' window is assigned a po- 
is sition m the stack onJer that is higher than the highest 
position assigned to ordinary windows. Consequently, if 
any window is manipulated in such a way as to overlap 
with the 'always on top' window, the overlapping portion 
of the "always on top' window will cover the other win- 
20 dow in the common screen region. 

This approach works well as long as there is only 
one window that contains crucial informatton. However, 
a problem arises when more than one "always on top" 
window is needed. In PC Tools for Windows, if two win- 
2S dows are designated as 'always on top' windows, they 
behave the same with respect to each other as normal 
windows do with respect to each other. That4s, one 'al- 
ways on top' window will have a higher stack order po- 
sltton than the other. When the two 'always on top" win- 
30 dows are caused to overlap, the higher-ordered window 
will cover the k>wer-ordered window in the common 
screen region. The information contained in the covered 
portbn of the lower-ordered window is no longer visble 
to the user. Thus, when more than one "always on top' 
3S window is displayed, there is no way to ensure that crit- 
ical informatbn will always be visible to the user. 

One way to avoid this probleni is to allow only one 
'always on top" window at a time. For example, French 
Patent Publication number 2.693,810 describes a win- 
40 dow management system that provides one window that 
cannot be obscured by other windows. When a user 
designates a second window as a non-obscurable win- 
dow, the first non-obscurable window ceases to be non- 
obscurable. Because this system does not support mul- 
4S tiple non-obscurable windows, its utility is limited 

Various different aspects of the present invention 
are set out in claims 1 , 9. 13, 21 and 22 hereof. 

According to a further aspect of the inventfon, a 
method and apparatus for establishing an always-visi- 
so ble class of windows in a computer-implemented win- 
dowing environment is provkied. A user may designate 
one or more windows as always-visible windows. If an 
always-visible window overlaps with a non-always-visi- 
ble window, then the always-visible window is displayed 
ss on top of the non-always-visible window. Always-visible 
windows are prevented from overlapping with each oth- 
er. Techniques are provided for implennenting the al- 
ways-visible window class in a manner that complies 
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with the X Windows system. According to one tech- 
nique, the override redirection attribute is used as a flag 
to designate which wiridows are always-visible win- 
dows. According to an alternative technique, a list of al- 
ways-visible windows is maintained as a property at- s 
tached to a root window. 

According to a further aspect of the invention, a 
method for displaying information on a display device of 
a computer system is provided. According to the meth- 
od, Infonmation is simultaneously displayed in a plurality io 
of windows on the display device. The plurality of win- 
dows includes a first always-visible window. A plurality 
of configurations that correspond to the plurality of win- 
dows is maintained. Specifically, the configuration for 
each window is maintained to reflect the location and '5 
dimensions of the window on the display device. 

An event that causes a portion of a second window 
to occupy a common region on the display device with 
a portion of the first always-visible window is detected. 
Upon detecting such an event, it is determined whether 
the second window Is also an always-visible window. If 
the second window is an always-visible window, then 
the configuration of one or both of the windows is altered 
to prevent overlap between the windows. If the second 
window is not an always-visible window, then the first 
window is displayed over the second window. 

According to another aspect of the invention, a 
stack order is maintained for the plurality of windows. 
User input is received which causes the second window 
to have a higher position in the stack order than the first 30 
always-visible window. If the second window is not an 
always-visible window, then the stack order is altered to 
cause the first always-visible window to have a higher 
position in the stack order than the second window. 

Varbus techniques may be used to designate a win- 35 
dow as an always-visible window. According to one em- 
bodiment, the overrkJe-redirect attribute provided in the 
X-wi'ndows system is used as a flag to designate al- 
ways-visible windows. According to another embodi- 
ment, a property attached to the root window is defined 40 
as an always-visible window list. To designate a window 
as an always-visible window, an entry that identifies the 
window is added to the always-visible window list. Both 
of these techniques may be used without deviating from 
the X-Windows standard. ^ 

Preferred embodiments of the invention described 
hereinbelow provide: 

a windowing system that albws information to be 
simultaneously displayed in multiple always-visible so 
windows; 

an always-visible class of windows in a window 
management system that is consistent with the cur- 
rent X-Windows standards; and 
a windows management system that allows users ss 
to combine window attributes including an always- 
visible attribute and a transparent background at- 
tribute. 



The present invention is illustrated by way of exam- 
ple, and not by way of limitation, in the figures of the 
accompanying drawings and in whk^h like reference nu- 
merals refer to similar elements and in which: 

Figure 1 illustrates a computer system upon which 
the preferred embodiment of the present inventkxi 
can be implemented; 

Figure 2 illustrates a display device that is simulta- 
neously displaying two always-visible windows and 
two normal windows on a screen according to an 
embodinrvent of the inventbn; 
Figure 3 illustrates the screen of Figure 2 after a 
user has selected a nonmal window that overlaps 
with an always-visible window; 
Figure 4 illustrates the screen of Figure 2 when the 
user is in the process of selecting and enlarging a 
normal window to cause the nomnal window to over- 
lap with an always-visible window; 
Figure 5 illustrates the screen of Figure 2 when the 
resize operatbn illustrated in Figure 4 has complet- 
ed; 

Figure 6 illustrates the screen of Figure 2 when a 
user has iattempted to nrK>ve an always-visible win- 
dow into a new positk>n that would cause the win- 
dow to overlap with another always-visible window; 
Figure 7 illustrates the screen of Figure 2 after the 
operation shovyn in Figure 6 showing how the win- 
dow being moved is not allowed to overlap with an- 
other always-visible window; 
Figure 8 illustrates the screen of Figure 2 when a 
user attempts to resize an always-visible window in 
such a way as to cause the always-visible to overlap 
with another always-visble window; 
Figure 9 illustrates the screen of Figure 2 afte the 
operatk)n shown in Figure 6; 
Figure 10 illustrates a functional bkxk diagram of a 
system that implements always-visible windows ac- 
cording to an embodiment of the inventkxi; 
Figure 11 illustrates a functional block diagram of a 
system that implements always-visible windows ac- 
cording to an alternate embodiment of the inven- 
tion; 

Figure 12a illustrates the operation of an X Client 
according to an embodiment of the inventfon; 
Figure 12b illustrates steps for designating an al- 
ways-visible window according to one emtxxliment 
of the inventton; 

Figure 12c illustrates steps for designating an al- 
ways-visible window according to an alternative 
embodiment of the inventk)n; 
Figure 13a illustrates the operatbn of a bump virin- 
dow manager according to an embodiment of the 
invention; 

Figure 13b Illustrates the steps performed by the 
bump window manager to initialize an always-visi- 
ble window list; 

Figure 13c illustrates the steps performed by the 
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bump window manager to process the atways-visi- 
ble window list to avoid overlap between always- 
visible windows; 

Figure 1 3d illustrates the steps performed by the 
bump window manager in response to detection of s 
an event which affects a window; and 
Figure 1 3e is a continuation of the flow chart illus- 
trated in Figure 13d. 

A method and apparatus for simultaneously dis- io 
playing multiple always-visible windows is described. In 
the following description, for the purposes of explana- 
tion, numerous specific details are set forth in order to 
provide a thorough understanding of the present inven- 
tion. It will be apparent, however, to one skilled in the is 
art that the present inventbn may be practiced without 
these specific details. In other instances, well-known 
structures and devices are shown HI block diagram form 
in order to avoid unnecessarily obscuring the present 
invenlk)n. 20 

Referring to Figure 1, the computer system upon 
which the preferred embodiment of the present inven- 
tion can be implemented is shown as 100. Computer 
system 100 comprises a bus or other communication 
moans 101 for communicating information, and a 2S 
processing means 102 coupled with bus 101 for 
processing Infonmatkxi. System 100 further comprises 
a random access memory (F)AM) or other dynamic stor- 
age device 104 (referred to as main memory), coupled 
to bus 101 for storing information and instructions to be 30 
executed by processor 1 02. Main memory 1 04 also may 
be used for storing temporary variables or other Inter- 
mediate Informatbn during executkm of instructbns by 
processor 102. Computer system 100 also comprises a 
read only memory (ROM) and/or other static storage de- 35 
vice 1 06 coupled to bus 1 01 for storing static information 
and instructions for processor 1 02. Data storage device 
107 is coupled to bus 101 for storing infomnatbn and 
instructions. 

Furthermore, a data storage device 107 such as a ^ 
magnetic disk or optical disk and its corresponding disk 
drive can be coupled to computer system 1 00. Compu- 
ter system 100 can also be coupled via bus 101 to a 
display devbe 121, such as a cathode ray tube (CRT), 
for displaying information to a computer user. An alpha- 45 
numeric Input devbe 122, including alphanumerb and 
other keys, Is typically coupled to bus 101 for commu- 
nicating informatbn and command selections to proc- 
essor 102. Another type of user input devbe is cursor 
control 1 23, such as a mouse, a trackball, or cursor di- so 
rection keys for communicating dlrectk>n Information 
and command selectbns to processor 102 and for con- 
trolling cursor movement on display 121. This input de- 
vice typically has two degrees of freedom in two axes, 
a first axis (e.g., x) and a second axis (e.g., y), which ss 
albws the device to specify positions in a plane. 

Aitematively, other input devices such as a stylus 
or pen can be used to interact with the display. A dis- 



played object on a computer screen can be selected by 
using a stylus or pen to touch the displayed object. The 
computer detects the selection by implementing a touch 
sensitive screen. Similarly, a light pen and a light sensi- 
tive screen can be used for selecting a displayed object. 
Such devices may thus detect selection position and the 
selection as a single operation instead of the 'point and 
click,' as in a system incorporating a nrK>use or trackball. 
Stylus and pen based input devices as well as touch and 
light sensitive screens are well known in the art. Such a 
system may also lack a keyboard such as 122 wherein 
all interface is provided via the stylus as a writing instru- 
ment (like a pen) and the written text Is interpreted using 
optbal character recognition (OCR) techniques. 

The present embodiment is related to the use of 
computer system 100 as a platform to execute applica- 
tion programs that support the display of multiple al- 
ways-visible windows. The preferred embodiment of the 
present Inventbn has been designed for use with the X- 
Windows system. The X-Windows system was original- 
ly devebped by MITs Project Athena and Digital Equip- 
ment Corporation, and is now managed by the X Con- 
sortium. The X-Windows system is described in detail 
in Xlib Reference Manual , volumes 1 and 2, O'Reilly & 
Associates, Inc. (1995). 

In the X-Windows system, functionality is distribut- 
ed between client applicatbns and a sen/er application. 
The client and server applications may be executing on 
a single processor on a single workstation, or may be 
distributed among multiple processors on multiple work- 
statbns that are connected over a network. 

Client Applications 

The client applications transmit requests to the 
sender applicatbn. The requests may include requests 
for the performance of a specified operatbn, or requests 
for information. The server applicatbn responds to the 
requests by performing the specified operation, or by 
sending a reply to the client application that includes the 
requested Information. 

Sender Applications 

In addition to sen^clng requests, the server appli- 
cation sends event messages and error messages to 
client applbatbns. Event messages inform the client ap- 
plications that some event has occurred. Typically, the 
client applications are designed to perform some action 
upon the receipt of certain event messages. Error mes- 
sages notify the client that a previous request from the 
client was invalid. 

The server application maintains complex abstrac- 
tions of resources. Such resources may include, for ex- 
ample, windows, pixmaps, cblonmaps, cursors, fonts, 
and graphics contexts. The abstractions for a resource 
contain attributes for the resource. For example, the ab- 
straction for a window includes informatbn about the 
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size, position, border width and stacking order of the 
window (the "configuration" of the window). 

Because the abstractions are maintained with the 
server, only one copy of the abstractions is required, re- 
gardless of how many clients use the resources. Since s 
clients do not have access to the abstractions them- 
selves, the clients must transmit requests to the server 
application to manipulate or retrieve informatbn about 
the resources. When a client transmits a request that 
relates to a resource, the client identifies the resource 
with an integer ID that corresponds to the resource. 
Since only an integer ID is sent rather than a complex 
abstraction, the traffic between the clients and the send- 
er is reduced. 

The Window Manager 

One special purpose client applicalion is referred to 
as the window manager. The window manager is a client 
application that has certain special responsibilities. Spe- 20 
cifically. the window manager mediates competing de- 
mands for the physical resources of a display, including 
screen space and the colormap. Typically, the window 
manager causes the server application to generate a us- 
er interface that allows a user to move windows about 2S 
on the screen, resize windows, and start new applica- 
tions. 

When a client application requests a change in the 
configuration of a window, the client application sends 
a request to the server. However, since the request re- 30 
lates to a responsibility controlled by the window man- 
ager, the server application does not service the re- 
quest. Instead, the sen/er application cancels the re- 
quest and transmits an event message that contains the 
arguments of the reconfiguration request to the window 35 
manager to inform the window manager of the reconfig- 
uration request. The window manager then detemiines 
whether the modifications specified in the reconfigura- 
tion request should be performed, modified, or denied. 
If the window manager detemiines that the modlfica- 40 
tions should be performed, then the window manager 
sends the reconfiguration request to the sender. Be- 
cause the reconfiguration request is from the window 
nranager, the server sendees the reconfiguration re- 
quest. If the window manager determines that the recon- 45 
figuration request should be modified, then the window 
manager sends a modified reconfiguration request to 
the server application. The process of sending reconfig- 
uration requests to the window manager for approval 
before the server acts upon the reconfiguration requests so 
is referred to as substructure redirection. 

Window Attributes 

As mentioned above, the sender appRcation main- ss 
tains complex data structures that contain information 
about resources. In addition to a window's configuration, 
the data structure for a window includes information 



about how the window is to look and act. This infonma- 
tion is referred to as window attributes. One attribute of 
a window is referred to as Substmcture Redirect Over- 
ride. The Substructure Redirect Override attribute de- 
termines whether a window wouki be allowed to be 
mapped on the screen without tnterventk>n by the win- 
dow manager. 

Always Visible Windows 

The present embodiment albws a client applk:atk>n 
to create and display windows that are always visible. 
Multiple always-visible windows may exist simultane- 
ously without defeating the always-visible nature of the 
windows. The always-visible windows may also exist si- 
multaneously with any number of normal windows. In 
this context, normal windows refers to all windows that 
are not always-visible windows. The general behavior 
of always-visible windows shall now be described with 
reference to Figures 2-8. 

Window Behavior 

According to the preferred embodiment of the in- 
vention, window behavior is governed by two simple 
niles. First, normal windows are never given higher po- 
sitrons in the stack order than always-visible windows. 
As a result, no portion of an always-visible window will 
ever be covered or obscured by a normal window. Sec- 
ond, always-visible windows are prevented from over- 
lapping with each other. As a result, no ponton of an 
always-visible window will ever be covered or obscured 
by any other always-visible window. 

These rules are illustrated in Figures 2-9. Referring 
to Figure 2, it illustrates a display device 200 that is si- 
multaneously displaying two always-visible windows 
204 and 206 and two normal windows 208 and 210 on 
a screen 202. A visual indicator 212 Is also shown on 
screen 202. Visual indicator 212 is used by a user to 
indicate a locatkxi on screen 202. Visual indicator 212 
moves across screen 202 in response to user manipu- 
lation of a user input device, such as a mouse or track- 
ball. 

In the state of screen 202 illustrated in Figure 2. win- 
dow 210 overlaps with and covers a portion of window 
208. Windows 204 and 206 overlap with and cover por- 
tions of window 210. No portbns of windows 204 or 206 
are covered by any other windows. 

As mentbned above, when two windows overlap, 
the determinatkxi of which window will cover the other 
hinges on the current positk>n of the windows in the 
stack order The window that is higher in the stack order 
is displayed in the overlapping region, thereby covering 
the windows that are kjwer in the stack order. Conse- 
quently, the state of screen 202 in Figure indfcates that 
window 210 is currently higher in the stack order than 
window 208, and that windows 204 and 206 are current- 
ly higher in the stack order than window 210. 
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Numerous window manipulation operations may 
cause two winck>ws to overlap. For example, a winciow 
may be moved from one location on screen 202 to an- 
other location on screen 202. In addition, a window may 
be resized to cover a jarger portion of screen 202. Other s 
window manipulation operations change the stack or- 
der. When the stack order is changed In such a way as 
to place a window that is covered by another window 
higher in the stack order than the window that is covering 
It, the window Is redrawn to cover the other window. In io 
typical windowing systems, a window must be selected 
before it can be manipulated. The select bn process 
may involve, for example, operating a user input device 
to position visual Indicator 212 over a visual portion of 
a window, and performing a predefined user input oper- is 
atlon (such as clicking a mouse button). In typical win- 
dowing systems, the setectbn of a window automatical- 
ly places the window at the top of the stack order. How- 
ever, as shall now be described with reference to Fig- 
ures 3 through 8, the present embodiment modifies this 
standard windowing behavk^r to support always-visible 
windows. 

Figure 3 illustrates screen 202 after a user has se- 
lected window 210. The borders of window 210 that are 
currently covered are illustrated with dashed lines. As 
mentk>ned above, in a typk^al windowing system, the se- 
lection of window 210 would cause window 21 0 to move 
to the highest position in the stack order. Therefore, win- 
dow 21 9 would be redrawn to cover the portbns of the 
other windows with whteh it overlaps. However, accord- 
ing to the present embodiment, a normal window such 
as window 210 is never moved to a higher position in 
the stack order than any currently existing always-visi- 
ble window. Consequently, the selection of window 210 
would not cause window 210 to move above windows 
204 and 206 In the stack order. Therefore, after the se- 
lectk)n of the window 21 0, screen 202 would still appear 
as illustrated In Figure 2. with portions of windows 204 
and 206 covering portions of window 21 0. Thus, the se- 
lectbn of a normal window that overlaps with one or 
more always-visible windows does not cause the normal 
window to be moved higher in the stack order than the 
always-visible windows. 

Referring to Figure 4, rt illustrates a situation which 
a user has selected and enlarged window 208. Normal- ^s 
ly, the selectton of 208 would cause window 208 to move 
to the highest posllton in the stack order. However, 
based on the window behavior rules implemented in the 
present embodiment, window 208 is placed In the high- 
est position in the stack order relative to other normal so 
windows, but remains lower In the stack order relative 
to all existing always-visible windows. Consequently, af- 
ter window 208 has been resized as illustrated in Figure 
4. screen 202 would appear as illustrated In Figure 5. 
Specifically, window 208 would be placed higher in the ss 
stack order than window 210, but still lower than win- 
dows 204 and 206. Thus windows 204 and 206 would 
still cover window 208, but window 208 would now cover 
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window 210. 

Figure 6 illustrates an attempt to cause two always- 
visible windows to overlap. Specifically. Figure 6 lllus- 
Irates the situation in which a user has attempted to 
move window 206 into a new position on screen 202 that 
would cause window 206 to overlap with window 204. 
As mentioned above, the present embodiment prevents 
two always-visible windows from overlapping. Conse- 
quently, rather than display wnndow 206 \n the position 
indicated by the user, the always-visible window that is 
being manipulated by the user is moved back to the ck>s- 
est non-overlapping previous positbn. The effect of this 
behavior Is that two always-visible windows appear to 
bunp Into each other instead of overlapping; Figure 7 
illustrates the position of window 206 after the operation 
performed in Figure 6. Specifically, window 206 is now 
adjacent to but does not overlap with vmdow 204. It 
shouki be noted that the position of an always-visible 
window in the stack order Is irrelevant with respect to 
other always-visible windows because always-visible 
windows are never allowed to overlap. 

Figure 8 illustrates an attempt to resize an always- 
visible window in such a way as to cause the always- 
visible window to overlap with another always-visible 
window. Specifically, window 206 has been resized to 
overlap window 204. As In the previous example, the 
present embodiment responds by limiting the resize op- 
eratk>n of window 206 to the closest non-overlapping 
previous position. This could result, for example, in the 
window positbns illustrated in Figure 9. 

It should be noted that moving the always-visible 
window operated on back to the closest non-overlap- 
ping previous position is simply one of many possible 
technkiues for Implementing the present invention. For 
example, overlaps between always-visible windows 
may also be prevented by retuming the operated-on al- 
ways-visible window to its initial state after any opera- 
tions which would othen/vise cause the always-visible 
window to overlap with another always-visible window. 

Altematively, overlap between always-visible win- 
dows may be prevented by allowing the movement of 
one always-visible window to "push" other always-visi- 
ble windows from their current positions. Thus, if a user 
attempted to move window 206 in Figure 9 upward, win- 
dow 204 would move upward along with it. Preferably, 
this upward repositioning of windows 204 and 206 woukJ 
be hatted as soon as window 204 reached the edge of 
screen 202, The "push" technique of preventing overlap 
between always-visible windows requires v^ndow man- 
agement routines that are more complex than are re- 
quired by other overlap-preventbn techniques. This 
complexity is due to the fact that the movement of one 
always-visible window may require the movement of 
any number of other always-visible windows (e.g. win- 
dow A pushes window B which pushes windows C and 
D, etc.). The present invenlbn is not limited to any spe- 
cific manner of implementing the window behavior rules 
descrlt)ed alcove. 
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General System Description 

Figure 10 illustrates a functional block diagram of a 
computer system 1 000 for implementing the window be- 
havior described above. The computer system 1 000 has 
a display device 1002, an input device 1004, and a win- 
dow management system 1006. The window manage- 
ment system 1006 manages the windows displayed on 
display device 1002. In the illustrated example, three 
windows 1008, 1010 and 1012 are currently displayed 
on display device 1002. 

The window management system 1006 generally 
includes a memory 1014, a window display unit 1018 
and an input reception unit 1020. The memory 1014 
contains a plurality of attributes 1022. 1024 and 1 026 of 
the windows displayed on display device 1002, The at- 
tributes 1 022, 1 024 and 1 026 that are stored in memory 
101 4 indicate for each window a stack order posltk)n, a 
screen position, a size (including vertical and horizontal 
dimensions) and whether the window is an always-vis- 
ible window. 

An "always-visible" attribute is not one of the normal 
window attributes defined and supported in the X-Win- 
dews specification. Consequently, a system which in- 
cludes a separately-defined always^islble attribute 
would constitute an extension to the X-Windows sys- 
tem, rendering the system incompatible with other sys- 
tems. Therefore, the always-visible attribute does not 
exist as a separately-defined window attribute in the pre- 
ferred embodiment. Rather, attributes and/or properties 
that pre-exist in the X-Windows system are used to store 
the value of the always-visible attribute. According to 
one embodiment, the "override-redirect" attribute, which 
is defined in the X-Windows specificatbn, is used as an 
•always-visible' flag. In an alternative embodiment, a list 
is attached as a property of a root window and used to 
identify always-visible windows. These embodiments 
shall be described in greater detail bek>w. 

Figure 10 illustrates the embodiment in whk:h the 
override-redirect attribute is used as an iaiways-visible 
window flag. In the illustrated example, attributes 1022 
include data indicating that window 1008 is not an al- 
ways-visible window, and that window 1008 is third in 
the stack order. Attributes 1024 include data indicating 
that window 1010 is not an always-visible window, and 
that window 1 01 0 is second in the stack order. Attributes 
1026 Include data Indk^tlng that window 1012 is an al- 
ways-visible window and that window 1012 Is first in the 
stack order. 

The window display unit 1018 causes display de- 
vice 1002 to display the windows 1008, 1010 and 1012 
based on the attributes 1022. 1024 and 1026 stored in 
memory 1014. If portions of two or more windows on 
display device 1002 share a common screen region, 
then the window display unit 1 01 8 causes display device 
1002 to display in the common screen region the portion 
of the window of the two or more windows that has a 
higher position in the stack order than the other win- 



dows. For example, windows 1008 and 1010 overlap. 
Because window 1010 is higher than window 1008 in 
the stack order, window 1010 is displayed in the overiap 

region. 

s The input reception unit 1020 is connected to the 
input device 1004 and receives input from a user. The 
Input may be, for example, input that designates chang- 
es in the attributes stored in merrory 1014. Window dis- 
play unit 1018 includes a plurality of units for processing 
the attribute changes. Specifically, window display unit 
1018 includes an overiap processing unit 1 028, an over- 
lap correction unit 1030. a stack order processing unit 
1032 and a stack order con-ectkxi unit 1034. 

The overlap processing unit 1028 determines 
whether the changes cause two or more always-visible 
windows to overlap. The overiap con'ectkxi unit 1030 
alters the plurality of attributes 1022. 1024 and 1026 as 
needed to prevent overiap between always-visible win- 
dows. The stack order processing unit 1032 determines 
whether the changes cause an always-visible window 
to have a tower positk^n in the stack-order than any win- 
dow that is not an always-visible window. The stack or- 
der correction unit 1034 alters the attributes 1 022, 1 024 
and 1026 as needed to prevent the always-visible win- 
dow from having a lower position in the stack-order than 
any window that is not an always-visible window. 

As described above, overlap processing unit 1 028 
and overlap correction unit 1030 cooperate to ensure 
that always-visible windows are never obscured by oth- 
er always visible windows. Similarly, stack order 
processing unit 1032 and stack order correction unit 
1034 cooperate to ensure that always-visible windows^ 
are never obscured by any window that is not an always- 
visible window. Consequently, always visible windows 
displayed on display devbe 1002 are never obscured 
by any other windows. 

Client-based Implementation 

As explained above, in the X-Windows system, win- 
dow manager clients typically control the mles that gov- 
ern user interface activity. All requests to affect the be- 
havtor or appearance of windows are first passed by the 
window manager through substructure redirectkxi. Cur- 
rent window managers do not support the behavk>r of 
always-visible windows described above. Consequent- 
ly, one embodiment of the present invention overrkles 
substructure redirectkxi for always-visible windows by 
setting the Substructure Override Redirect attribute of 
always-visible windows. Because the Substmcture 
Override Redirect attribute is only set for always-visible 
windows, the value of the Substructure Override Redi- 
rect attribute also serves as a flag to distinguish always- 
visible windows from normal windows. 

Once a client applicatkxi that implements the 
present invention has identified the always-visible win- 
dows, as described above, the client maintains its own 
list of always-visible windows! The list contains infornna- 
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tion about each always-visible window, including the 
window ID. location and dimensions of the window. 

The client then tracks all graphics events which may 
affect the visibility of the always-visible windows. If any 
graphic event would cause any portion of an always-vis* s 
ibie window to become obscured, the client modifies the 
event to enforce the window behavior rules described 
above. Specifically, the client detects when a normal 
window is placed at the top of the stacking order and 
immediately transmits requests that cause all always- 10 
visible windows to be placed higher in the stack order 
than the normal window. The client also detects when 
an always-visible window is moved or resized. The new 
position and size is compared with all other always-vis- 
ible windows. If the window movement or size change is 
causes the always-visible window to overlap with one 
or nrKjre other always-visible windows, then the client 
transmits a request to reposition or resize the always- 
visible window to the ctosest non-overlapping position. 

Window Manager-based Implementation 

Rather than implement the present invention in a 
client applicatk^n that circumvents the window manager 
to implement always-visible windows, the present in- 
vention may be implemented in a window manager. 
Similar to the client implementatton, the window man- 
ager wouki nnaintain a list of the always-visible windows 
and counteract events that would cause any portion of 
an always-visible window to become covered or ob- 
scured. However, to prevent other clients from perform- 
ing Qperatk>ns that wouki obscure a portion of an al- 
ways-visible window, a flag other than the Substrut^ure 
Override Redirect would be used to identify always-vis- 
ible windows. For example, a list of always-visible win- 
dows (an "always-visible window list*) may be defined 
and created as a property attached to the root window. 

Referring to Figure 11, it illustrates an embodiment 
in which an always-visible window list 1102 is used to 
identify always-visible windows. The always-visible list ^ 
1102 includes a window kientifier for each existing al- 
ways-visible window. Specifically, always-visible win- 
dow list 1102 includes an entry 1104 that con-esponds 
to window 1012, which is the only always-visible window 
on display device 1002. During a resize window, select ^ 
window or move window operation, window display unit 
1018 accesses the always-visible windows list 1102 to 
determine whether particular windows are always-visi- 
ble windows. Using an always-visible window list to 
identify always-visible windows allows joint control of al- so 
ways-visible windows by window display unit 1016 and 
a normal X system window manager. 
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X Client Applbation Operation 

Referring to Figure 12a. it is a flowchart illustrating 
the operatbn of an X Client application according to an 
embodiment of the invention. The X Client is designed 



ss 



to designate one or more windows as being "always vis- 
ible'. As discussed above, there are varbus possible 
methods for designating a window as an always-visible 
window. Reference to Figures 12b and 12c shall be 
made to describe two such methods. According to the 
first technique, all windows whkii have the 'overrkie re- 
direct" attribute set are "always-visible" windows: Ac- 
cording to the second technique, a list of window IDS 
for all always-visible windows is maintained In the form 
of a property attached to the root window. When this 
technkiue is used, each applk^tkxi whk^h creates an al- 
ways-visible window is responsible for adding the win- 
dow ID to the always-visible window list at the time the 
window is created. A bump window manager, which will 
be described hereafter, removes the ID of an always- 
visible window from the always-visible window list auto- 
matically at the time that the always-visible window is 
destroyed. 

Referring now to Figure 12a, an X client connects 
to an X-Server at step 1202. The X Client connects to 
the X-Sen^er by making an Xlib call that establishes a 
communications path between the X Client and a des- 
ignated X-Server. .. . 

At step 1 204, the X Client creates a window. At step 
1208, the X Client designates that the window created 
in step 1204 Is an always-visible window. As explained 
above, the window may be designated as an always- 
visible window according to one of any number of tech- 
niques. One technique is illustrated in Figure 12b. Ac- 
cording to this technque. the Override-Redirect At- 
tribute of the window is set at step 1216. 

An alternative technkiue for designating a window 
as an always-visible window is illustrated in Figure 12c. 
According to the technique illustrated in Figure 12c, the 
root window has a property which is defined as an al- 
ways-visible windows list. At step 1218, the always-vis- 
ible windows list property Is retrieved. At step 1220 a 
window ID that corresponds to the newly created win- 
dow is added as an entry into the always-visible win- 
dows list. At step 1222, the properly of the root window 
that corresponds to the always-visible windows list is up- 
dated to reflect the revised always-visible windows list. 

Referring again to Figure 12a, the window is 
mapped at step 1210. Mapping the window causes the 
window to be displayed on the appropriate display. At 
step 1 212, the client performs all client processing. This 
step generally representstheoperatton of the client The 
steps actually performed during this step will vary based 
on the X Client and interaction between the X Client, the 
user, and other applicatkxis. During the X Client opera- 
tion, vark>us events may occur whk:h affect the always- 
visible window. For example, other windows (both al- 
ways-visible windows and non-always-visible windows) 
nruay be created, mapped, moved, resized and de- 
stroyed. When the X Client Is through with all process- 
ing, the X Client destroys the window at step 1214. 
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Bump Window Manager Operation 

According to one embodiment of the invention* a 
bump window manager is used to create the window be- 
havior described above. A bump window manager may s 
be a component of an X Windows manager or may co* 
exist-exist separately from an X Windows manager. The 
purpose of the bump window manager is to identify and 
monitor windows which have been designated as al- 
ways-visible windows. If the staclcing order is changed, io 
the bump window manager ensures that all always-vis- 
ible windows are stacked above all other windows. If an 
always-visible window is moved or resized, then the 
bump window manager will check for overlapping con- 
ditions with other always-visible windows. If such an is 
overlap condition occurs, then the bump window man- 
ager will issue a move or resize operation to place the 
always-visible window on which the operatbn was per- 
formed at a prevbus position or size which does not 
overlap any other always-visible window. The operation 20 
of the bump window manager will be described in great- 
er detail with respect to Figures 1 3a, 1 3b, 1 3c, 1 3d and 
Ide. 

Figure 13a is a flowchart illustrating the operatbn 
of a bump window manager. At step 1 302, the bump win- 
dow manager connects to the XServer, This establish- 
es a communk:atk>n path between the bump window 
manager and a specified X-Server. 

At step 1 304, the bump window manager initializes 
an always-visible window list. Referring to Figure 13b, 30 
it shows the steps performed by the bump window man- 
ager during step 1304 in greater detail. Specifically, at 
step 1314, the bump window manager queries the X- 
Sen^er for a list of windows. At step 1 31 6. the bump win- 
dow manager Identifies the always-visible windows In 3S 
the list of windows and creates a list of the always-visible 
windows. Preferably, all always-visible windows are 
children of the root window. 

The method used by the bump window manager to 
identify which of the windows identified by the X-Sen^er ^ 
are always-visible windows depends on the technique 
used to designate always-visible windows. For exam- 
ple, if the override-redirect attribute is used as a flag to 
designate always-visible windows, then the bump man- 
ager inspects the override-redirect attribute of all the ^ 
windows identified by the X-Server. It a property at- 
tached to a root window is used to list the always-visible 
whdows, then the bump window manager inspects the 
appropriate property of the root window. 

At step 1318. the bump window manager queries 
the X-Server for the size arrd position of alt of the always- 
visible windows. At step 1320, the bump window man- 
ager stores in an always-visible window list the sizes, 
positbns. and window status of each of the always-vis- 
ible windows. Consequently, the entry for each always- 55 
visible window in the always-visible window list includes 
the window ID, location, size, status (map/unmap) and 
stacking order of the always-vistole window. 



At step 1 322, the bump window manager processes 
the new list. The operatbns performed by bump window 
manager to process the new always-visible window list 
are illustrated in Figure 13c. Referring to Figure 13c, 
steps 1 326. 1 338 and 1 340 f onm a loop that is repeated 
until an overlap between mapped always-visible win- 
dows is encountered or until the entries for all of the al- 
ways-visible windows have been processed. The infor- 
mation in an unmapped window cannot be obscured by 
another window because the information It is not even 
displayed. Therefore, in the preferred embodiment, 
overlap between an unmapped always-visible window 
and any other always-visible window is ignored. 

When an overlap is er>countered between a partic- 
ular mapped always-visible window and one or more 
other mapped always-visible windows, then control 
passes from step 1 326 to step 1 328. At step 1 328, the 
bump window manager determines a new position for 
the particular always-visible window which avoids over- 
lap between the always-visft)le window and all other 
mapped always-visible windows. At step 1330, it is dOr 
termined whether such a position exists. If such a posi- 
tion exists, then the always-visible window is moved to 
the position at step 1336. If such a position does rK>t 
exist, then control passes to step 1332. 

At step 1332, the bump window manager deter- 
mines whether the size limit of the always-visible win- 
dow has been reached. In this context, the size limit is 
the minimum size that the always-visible window is al- 
bwed to assume. If the size limit for the always-visible 
window has been reached, then control passes to step 
1 338 and the next always-visible window entry in the listr 
is processed. If the size limit for the always-visible win-:.^ 
dow has not been reached, then the size of the always- 
visible window is reduced. Steps 1326. 1328. 1330, 
1 332 and 1 334 form a loop such that the size of an al- 
ways-visible window will be reduced until either the win- 
dow can be moved to a non-overlapping position or its 
size limit has been reached. 

Ref ening again to Figure 1 3a. when the always-vis- 
ible window list has been initialized, the bump window 
manager waits for a window event (step 1306). When a 
window event occurs, control passes to step 1308 
where the window event is window event occurs, control 
passes to step 1308 where the window event is proc- 
essed. Step 1308 shall be described in greater detail 
with reference to Figures 1 3d and 1 3e. 

Referring to Figure 13d and 13e, they illustrate a 
flowchart of the steps performed by the bump window 
manager when a window event takes place. At step 
1342 the bump window manager receives data that 
klentif ies the event that has occurred. At steps 1 344 to 
1358, the bump window manager kientifies the type of 
event whteh has occurred. 

If the event specifies that a particular window is to 
be moved, then control passes from step 1 344 to step 
1360. At step 1360. the bump window manager deter- 
mines whether the window on which the operatbn is to 
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be performed is an always-visible window. If the window 
IS not an always-visible window, then the bump window 
manager need not perform any further processing in re- 
sponse to the window event. If the window is an always- 
visible window, then control passes to step 1 376. At step 
1376, the bump window manager detemiines whether 
the move will cause the always-visible window to over- 
lap with another always-visible window. If not. then the 
bump window nnanager need not perfonm any further 
processing in response to the window event. Othenvise, 
the always-visible window is moved to a non-overlap lo- 
cation In step 1384. The non-overlap location may be, 
for example, adjacent to but not overlapping with the 
other always-visible window. At step 1390, the entry in 
the always-visible window list that corresponds to the 
window that was moved is updated to reflect the new 
location of the window that was moved. 

If the event specifies that a particular window is to 
be resized, then control passes from step 1 346 to step 
1 362. At step 1 362, the bump window manager deter- 
mines whether the window on which the operation is to 
be performed is an always-visible window. If the window 
is rK>t an always-visible window, then the bump window 
manager need not perform any further processing in re- 
sponse to the window event. If the window is an always- 
visible window, then control passeis to step 1 378. At step 
1378, the bump window manager determines whether 
the resize operation wilt cause the always-visible win- 
dow to overlap with another always-visible window. If 
not, then the bump window manager need not perform 
any further processing in response to the window event. 
Otherwise, the always-visible window is resized to a size 
in which the always-visible window does not overlap 
with any other always-visible window in step 1 386. The 
new size of the window will be smaller than the size 
specified in the resize event. For example, the size may 
be a size which causes the border of the resized window 
to be adjacent to but not overlapping with the border of 
the other always-visible window. At step 1 392, the entry 
in the always-visible window list that corresponds to the 
window that was resized is updated to reflect the new 
size of the window that was resized. 

If the event specifies a change in the stacking order, 
then control passes from step 1 348 to step 1 364. At step 
1364, the bump window manager determines whether 
any non-always-visible window is above any always-vis- 
ible window in the new stacking order. If no non-alvvays- 
visible window is above any always-visible window in 
the new stacking order, then the bump window manager 
need not perform any further processing in response to 
the window event. If any non-always-visible window is 
above any always-visible window in the new stacking 
order, then control passes to step 1380. At step 1380, 
the bump window manager adjusts the new stacking or- 
der to ensure that all always-visible windows are above 
all non-atways-visible windows in the stacking order. 

If the event specifies that a particular window is to 
be created, then control passes from step 1 350 to step 



1366. At step 1366. the bump window manager deter- 
mines whether the newly created window is an always- 
visible window. If the window is not an always-visible 
window, then at step 1382 the bump window manager 
s adjusts the stacking order to ensure that all always-vis- 
ible windows are above all non-always-visible windows 
in the stacking order If the window is an always-visible 
window, then control passes to step 1 388. At step 1 388 
an entry is added to the always-visible window list for 
10 the newly created always-visible window. 

If the event specifies that a partk:ular window is to 
be destroyed, then control passes from step 1352 to 
step 1 368. At step 1 368, the bump window nnanager de- 
temiines whether the window on which the operatbn is 
75 to be perfonmed is an always-visible window. If the win- 
dow Is not an always-visible window, then the bump win- 
dow manager need not perform any further processing 
in response to the window event. If the window is an 
always-visible window, then control passes to step 
^0 1 396. At step 1 396, the always-visible window list is up- 
dated. Specifically, the entry for the always-visible win- 
dow that is to be destroyed is removed from the always- 
visible window list. 

If the event specifies that a partrcular window is to 
2S be mapped, then control passes from step 1 354 to step 
1370. At step 1370. the bump window manager deter- 
mines whether the window on which the operatbn Is to 
be performed is an always-visible window. If the window 
is not an always-visible window, then the bump window 
30 manager need not perfonm any further processing in re- 
sponse to the window event. If the window is an always- 
visible window, then control passes to step 1 398. At step 
1398, the always-visible window list is updated. Specif- 
ically, the map/unmap status in the entiy for the always- 
35 visible window is revised to reflect that the always-visi- 
ble window is mapped. Once the entiy has been revised, 
the always-visible window list Is processed at step 1 394 
to ensure that no nr\apped always-visible windows over- 
lap with any other mapped always-visible windows. The 
^ steps involved in processing the always-visible window 
list are described above with reference to Figure 13c. 

If the event specifies that a particular window is to 
be unmapped, then control passes from step 1356 to 
step 1 372. At step 1 372, the bump window manager de- 
^ termines whether the window on which the operation Is 
to be perfonmed is an always-visible window. If the win- 
dov^ is not an always-visible v/indow, then the bump win- 
dow manager need not perform any further processing 
in response to the window event If the window is an 
so always-visible window, then control passes to step 
1400. At step 1400, the always-visible window list is up- 
dated. Specifrcally. the map/unmap status in the entry 
for the always-visible window is revised to reflect that 
the always-visible window is no kDnger nnapped. 
55 If the event specifies that a property of a partbular 
window is to be changed, then control passes from step 
1 358 to step 1 374, At step 1 374. the bump window man- 
ager detenmines whether the property to be changed is 
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an always-visible window list. If the property to be 
changed is not an always-visible window list, then the 
bump window manager need not perform any further 
processing in response to the window event. If the prop- 
erty to be changed is an always-visible window list, then 
control passes to step 1402. At step 1402 the always- 
visible window list Is revised as specified in the event. 
Once the always-visible window list has been revised, 
the always-visible window list is processed at step 1404 
to ensure that no mapped always-visible windows over- 
lap with any other mapped always-visible windows. The 
steps involved in processing the always-visible window 
list are described atove with reference to Figure 1 3c. 

Referring again to Figure 13a, steps 1306. 1308 
and 1 31 0 define a loop In which window events are proc- 
essed as described abwe until a condition occurs which 
causes the bump window manager to terminate. Upon 
the occurrence of such a condition, control passes from 
step 1 31 0 to step 1 31 2. At step 1 31 2, the bump window 
manager closes the connection that has been estab- 
lished between the bump window manager and the X- 
Sen^er. 

Transparent Backgrounds 

According to a prefen^ed aspect of the invention, it 
is desirable to provide always-visible windows that have 
a transparent background A transparent background 
atbws a user to see the screen regions that are covered 
by the window Only the foreground data within the win- 
dow is not transparent. By providing always-visible win- 
dows with transparent backgrounds, one can ensure 
that certain data will always be visible and yet minimize 
the amount of Infonrnation that is obscured by the al- 
ways-visible window. 

Possible Appfrcations 

The always-visible windows provided by embodi- 
ments of the invention are ideal for use in any computer 
application that requires the constant display of critk:al 
information. For example, in air traff k: control certain da- 
ta pertaining to aircraft must not be covered by any other 
infonmalion. Previously, this constraint did not allow air 
traffic control applk:atk)ns to take advantage of win- 
dows-based environments. However, by displaying the 
critical data in always-visible windows, air traffic control 
applications can take advantage of the convenience 
provided by windows-based graphk;al environments. 
Air traffic control is just one example of a fieki whk;h 
would benefit signrTicantly from the present invention. 
However, the present invention is not limited to any spe- 
cific field of use. 

While specific embodiments of the present inven- 
tion have been described, varbus nrxxiifications and 
substitutions will become apparent by this discbsure. 
Such modificatbns and substitutions are within the 
scope of the present invention, and are intended to be 
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Claims 

5 

1. A method for displaying infomiatton on adisplay de- 
vice of a computer system, the method comprising 
the steps of: 

10 simultaneously displaying informatbn in a plu- 

rality of windows on said display device, where- 
in said plurality of windows includes a first al- 
ways-visible window; 

maintainvig a plurality of configuratbns that 
IS correspond to sakJ plurality of wirKbws, where- 

in the configuration for each of saki plurality of 
windows reflects a locatbn and dimensions of 
the window on the display devbe; 
detecting an event that causes a portbn of a 
20 second window of said plurality of windows to 

occupy a common regbn on said display de- 
vice with a portk>n of sakdl first always^isible 
window; 

determining whether said second window is an 
2S always-visible window; 

if said second window is an always-visible win- 
dow, then 

altering either the configuratbn of the first always- 
30 visible window or the configuration of the second 
window, or the configurations of both said first al- 
ways-visible window and second window, so that no . 
portion of said second window occupies a common \ 
region on said display device with any portion of 
3S sakJ first always-visble window. 

2. The method of Claim 1 further comprising the step 
of: 

if said second window is not an always-visible wln- 
40 dow, then 

displaying said portion of said first window in sakJ 
common region. 

3. The method of Claim 1 wherein: 

45 

sakJ first window has a transparent back- 
ground; 

said step of displaying said portion of sab first . 
window in sab common regbn includes the 
so steps of 

displaying in said common regbn informa- 
tion from said first window, and 
displaying in said comnnon regbn informa- 
ss tion from a non-transparent window that 

overlaps with sakJ first window. 

4. The method of Claim 1 further comprising the steps 
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maintaining a stack order for said plurality of 
windows, wherein each window of said plurality 
of windows has a position in said stack order, 5 
receiving user input to cause said second win- 
dow to have a higher position in said stack order 
than said first always-visible window; 
if said second window is not an always-visible 
window, then altering said stack order to cause io 
said first always-visible window to have a high- 
er position in sakJ stack order than said second 
window. 

5. The method of Claim 1 wherein each of said plural- is 
ity of windows includes an overrkje-redirect at- 
tribute, wherein said step of determining whether 
said second window is an always visible window In- 
cludes the step of detemnining whether the over- 
rkje-redirect attribute is set. 

6. The method of Claim 1 wherein: 

said plurality of windows include a root window; 
said root window has a property that is defbied 
as an always-visible window list; 
saki always-visible window list includes an en- 
try for each.of sakJ plurality of windows that is 
an always-visible window; and 
said step of determining whether said second 
window is an always visible window includes in- 
specting said always-visible window list to de- 
termine whether said always-visible window list 
includes an entry for sad second window. 

7. The method of Claim 6 further comprising the steps 
of: 

detecting an event that destroys said first al- 
ways-visible window; and 
removing an entry that corresponds to said first 
always-visible window from said always-visible 
window list. 

8. The method of Claim 6 further connprising the steps 4S 
of: 

detecting an event that creates a new always- 
visible window; 

the method further comprising adding an entry so 
that corresponds to said new always-visible 
window to said always-visible window list; 
determining whether said new always-visible 
window overlaps with any other always-visible 
window; and ss 
if sakJ new always-visible window overlaps with 
any other always-visible window, then altering 
either the configuratk^n of the new always-vis- 
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ibie window or the configuration of the other al- 
' ways-visible window, or the configurations of 
both said new always-visble window and the 
other always-visible window, so that no portbn 
of said new always-visible window overlaps 
sakJ other always-visible window. 

9. A window management system for use on a com- 
puter system that has a display device, the window 
management system comprising: 

a memory that contains a plurality of attributes 
of a plurality of windows, wherein said plurality 
of attributes indicate whether each window of 
said plurality of windows is an always-visible 
window, wherein said plurality of attributes in- 
dicate a stack order position for each vtnndow 
of sakJ plurality of windows; 
an input receptton unit for receh/ing Input from 
a user, said input designating chariges In said 
plurality of attributes; 

a window display unit for displaying sakI plural- 
ity of windows on said display devtee based on 
said plurality of attributes; 
wherein if portions of two or more windows of 
said plurality of windows share a common 
screen region, then the window display unit dis- 
plays In said common screen region the portion 
of the window of said two or more windows that 
has a higher position in said stack order than 
the other of said or wore windows; 
wherein the window display unit includes 

an overiap processing unit for detemnining 
whether sakJ changes cause two or more 
always-visible windows to overiap; and 
an overlap correction unit for altering said 
plurality of attributes to prevent overlap be- 
tween sakJ two or more always-visible win- 
dows; 

a stack order processing unit for determin- 
ing whether saki changes cause an al- 
ways-visible window to have a lower posi- 
tion in said stack-order than any window 
that is not an always-visible window; and 
a stack order correcton unit for altering 
said plurality of attributes to prevent said 
always-visible window from having a lower 
positk>n in said stack-order than any win- 
dow that is not an always-visible window. 

10. The window management system of Claim 9 further 
including a mechanism for maintaining a record of 
which of said plurality of windows are always-visible 
windows. 

11. The window management system of Claim 10 
wherein: 
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said plurality of attributes include an override 
redirect attribute; and 

said mechanism maintains said record by set- 
ting the override redirect attribute of each of 
said plurality of windows to reflect whether said s 
window Is an always-visible window. 

12. The window management system of Claim 10 
wherein: 

10 

said plurality of windows include a root window; 
said root window has a property defined as an 
always-visible window list; 
said mechanism maintains said record by stor- 
ing an entry into said always-visible window list is 
for each of said plurality of windows that is an 
always-vlsibie window. 

13. A method for displaying important information in a 
window-based interface on a screen of a display de- ^ 
vice in a computer system, the method comprising 
the steps of: 

displaying a plurality of windows on said 
screen, said plurality of windows including one 
or more always-visible windows; 
displaying said important information in an al- 
ways-visible window of said plurality of win- 
dows; 

receiving user input that would cause a select- 30 
ed window of said plurality of windows to cover 
a portion of said always-visible window; 
if said selected window is an always-visble win- 
dow, then preventing said selected window 
from overlapping with said alway8-visft)le win- ^ 
dow, and 

if said selected window is not an always-visible 
window, then displaying on said screen said al- 
ways-visible window on top of said selected 
window. ^ 

1 4. The method of Claim 1 3 further comprising the step 
of detecting when said user input would cause said 
selected window to overlap any of said one or more 
always-visible windows by performing the steps of: ^ 

storing orientation data that Indicates a region 
of the screen that corresponds to each of said 
one or more always-visible windows; 
detecting when an attempt is made to display so 
said selected window in a new region on said 
screen; and 

comparing the new region with the orientation 
data to determine if the new region intersects 
with the region of the screen that corresponds ss 
to any of said one or more always-visible win- 
dows. 



15. The method of Claim 1 3 further comprising the step 
of: 

nnaintaining a stack order for said plurality of 
windows; 

displaying said plural'rty windows on said 
screen responsive to said stack order, wherein 
if any windows of said plurality of windows over- 
lap, then the window with a higher position In 
saki stack order is displayed above the win- 
dows with which It overlaps; 
detecting when said user input would cause 
any window that is not an always-visible win- 
dow to assume a higher posltkxi in a stack or- 
der than any of sakI one or more always-visible 
windows; and 

causing said any window to assume a position 
in said stack order that is lower than all of said 
one or niore always-visible windows. 

16. The method of Claim 1 3f urther comprising the step 
of designating said always-visible window as an al- 
ways-visible window by perfonning the step of set- 
ting an override-redirect attribute of said always-vis- 
ible window. 

17. The method of Claim 1 3 further comprising the step 
of designating said always-visible window as an al^ 
ways-visible window by performing the steps of: 

creating an always-visible window list; and 
adding to said always-visible window list an en- 
try that corresponds to said always-visible win- 
dow. 

18. The method of Claim 1 7 wherein said step of creat- 
ing an always-visible window list includesestablish- 
ing said always-visible window list as a property of 
a root window. 

19. The method of Claim 1 7 wherein said entry includes 
a window identifier, a k3catk)n indbalor, a size indi- 
cator and a stacking order indicator for said always 
visible window. 

20. The method of Claim 19 wherein said entry further 
Includes data that indteates whether said always 
visible window is mapped. 

21. A computer-readable medium that has stored ther- 
eon sequences of instructkxis whk:h, when execut- 
ed by a processor, cause the processor to perf orm 
the method recited in Claim 13. 

22. A windows-based computer system that supports 
windows from a plurality of windows classes, 
wherein a partk:ular window class of the plurality of 
windows classes corresponds to wirxiows that can- 
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not be obscured by any other windows. 

23. The windows-based coniputer system of Claim 22 
further comprising a window display unit configured 
toprevent overlap between any two windows of said s 
particular window class. 

24. The windows-based computer system of Claim 23 
wherein said window display unit is further config- 
ured to allow overlap between a window of said par- io 
ticular window class and a window that is not of said 
particular window class. 

25. The windows-based computer system of Claim 24 
wherein said window display unit is further config- is 
ured to detect overlap between the window of said 
particular window class and the window that is not 

of said particular window class, and to display the 
window of said particular window class on top of the 
window that is not of said particular window class. 20 

26. The windows-based computer system of Claim 23 
wherein said window display unit prevents overlap 
between two windows of said particular window 
class by causing said windows to appear as if said ss 
two windows were bumping against each other 
when a user attempts to peiform an operation that 
would otherwise cause said two windows to over- 
lap. 
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